Fix silent brute force fallback at aligned vector dimensions - #2483

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

/ok to test c87fcd4

I see what you're doing here; I'm generally 👍.

But I think what you've mentioned in #2482 is a serious point: It does feel like there is room to iron out the API a little better. Leaving it to the caller to remember to call isPaddedDataset() isn't completely foolproof. For instance:

1. This fix seems geared towards cuvs-lucene working properly. Since we haven't changed the C-API at all, your Python example is still vulnerable to breakage, unless I'm mistaken.
2. All future Java call sites will have to repeat the pattern we have established here.

We can check this in now. But I'm wondering if we should consider a more foolproof approach in the future.

I toyed with the idea of making CuVSMatrix etc. a reference counted Closeable:

1. Every time the instance is copied, we increase the reference count.
2. Every time it's closed, we decrement the reference count.
3. Once it is closed for the last time, the reference count goes to 0. That's when it's actually closed.

This will allow us to have makePaddedDatasetView(dataset) return a Tuple< CuVSMatrix, View >:

1. If already padded, return the argument dataset and a view into it.
2. If not padded, return a copied, padded dataset and a view to that.
   In both cases, both returns are handled with try-with-resources. They are closed on end of scope.

The consumption code would look something like:

      var tuple = index.makePaddedDatasetView(deviceVectors);
      try (
        var dataset = tuple.first();
        var view    = tuple.second()
      ) {
        index.updateDataset(view);
        index.serialize(os);
      }

Does something like that make sense for the future?

/ok to test 2cb1b39